In recent years, the usage of mobile telecommunication systems for receiving and transmitting data packets becomes more and more important. In order to reach high transmission rates and better resource utilization in comparison with the circuit switching originally designed for voice sessions, a packet orientated communication network infrastructure for packet switching was introduced in the mobile telecommunication systems, for example, the General Packet Radio Service (GPRS) within, e.g., the GSM system or the Universal Mobile Telecommunication Service (UMTS) in 3rd generation systems.
To support different network protocols such as internet protocol (IP) and the like, these new services require new network nodes in a core network. In the case of the above mentioned GPRS or UMTS, one of these nodes is a Serving GPRS Support Node (SGSN), keeping track of individual terminals, e.g. user equipment UE, such as mobile stations, and performing security functions and access control. The SGSN is connected to another new node, the Gateway GPRS Support Node (GGSN), which provides interworking with external packet switched networks.
The detailed hierarchical arrangement and network elements, as e.g. shown in FIG. 1, of a packet switched network is described below. In this case, a UMTS-communication system is shown. Other systems, like the GPRS-system, have a similar structure.
A communication area covered by the network is divided in several routing areas RA each controlled by a distinct serving node SGSN. Within said routing area, at least one access network, e.g. a radio access network (RAN), consisting of a access network controller, e.g. a radio network controller RNC, and associated transceiver stations is provided for establishing a communication connection between a user equipment UE within said routing area and the core network comprising the SGSN and the GGSN.
When the user equipment UE being in a mobility management (MM) connected state (i.e. connection between the user equipment UE and the core network is active) is moved from a communication area covered by a first radio network controller (i.e., the access network controller) to a communication area covered by a second radio network controller, a relocation procedure of the serving radio network controller (SRNC relocation procedure) is required for switching control to the second RNC. In the case that said second radio network controller RNC is in another routing area RA and therefore connected to a second serving node SGSN, additionally an inter SGSN relocation has to be executed.
The SRNC relocation procedure in combination with a routing area change (i.e. a SGSN change) of the user equipment as conventionally performed will now be explained with reference to FIGS. 2A and 2B. This combined relocation is referred herein below as an “inter SGSN SRNC relocation procedure”.
In the communication network, e.g. in the serving radio network controller SRNC, a decision is taken that a SRNC relocation procedure has to be performed. This includes a decision as to which radio network controller RNC will be the next serving radio network controller SRNC. The first SRNC (RNC1) sends a SRNC relocation request message 1 to the first serving node SGSN1 which message indicates the need for SRNC relocation. This message includes parameters such as identifier of the new SRNC. Upon receipt of the SRNC relocation request message 1, the serving node SGSN1 determines from the received information that the SRNC relocation will also result in a change of the serving node SGSN. The SGSN1 then sends a forward SRNC relocation request message 2 to a new serving node SGSN2 including the information received from the first SRNC (RNC1) and necessary information for the change of the SGSN (e.g. MM context, Packet Data Protocol (PDP) context). Then, the SGSN2 sends a SRNC relocation request message 3 to the new SRNC (RNC2). This message includes information for establishing the SRNC context, transparently sent from the first radio network controller RNC1 (e.g. user equipment identity, user equipment capability information and the like). When the second radio network controller RNC2 completed its preparation phase, a SRNC relocation proceeding message 4 is sent to the second serving node SGSN2. When traffic resources between the RNC2 and the SGSN2 have been allocated and the SGSN2 is ready for the SRNC change, then a forward SRNC relocation response message 5 is sent from the serving node SGSN2 to the serving node SGSN1. This message indicates that necessary resources have been allocated for the SRNC relocation. When the first serving node SGSN1 receives the forward SRNC relocation response message 5, the SGSN1 indicates the completion of the preparation phase at the core network side for the SRNC relocation by sending a SRNC relocation proceeding message 6 to the first radio network controller RNC1. After receiving the SRNC relocation proceeding message 6, the RNC1 sends a SRNC relocation commit message 7 to the second radio network controller RNC2. The RNC2 executes a switching of all bearers at the earliest suitable time instance. Immediately after a successful switching to the RNC2, the RNC2 (which is now the SRNC) sends a SRNC relocation complete message 8 to the second serving node SGSN2. The RNC2, acting as SRNC, sends also new MM system information 9 to the user equipment UE indicating, e.g., the current relevant routing area. The second serving node SGSN2 sends a complete SRNC relocation message 10 towards the SGSN1. Upon receipt of the complete SRNC relocation message 10, the SGSN1 sends a release indication message 11 to the RNC1. This implies release of all radio access network resources of the RNC1 related to the user equipment UE.
At this time, the control in the radio access network is switched from the first radio network controller RNC1 to the second radio network controller RNC2. Hence, with reference to FIG. 1, data flows from the user equipment UE via the radio network controller RNC2 to the serving node SGSN2, to the serving node SGSN1, to the gateway node GGSN and therefrom to the external network in uplink direction and vice versa in downlink direction. The first serving node SGSN1 is involved because control in the core network is still at the SGSN1. However, it is to be noted, that additional steps (or messages) may be introduced in the above described relocation procedure depending on which procedure is used for the inter SGSN relocation. These steps will be described herein below, respectively, in connection with the known inter SGSN relocation procedures.
Hitherto, two solutions are known for the above mentioned inter SGSN SRNC relocation procedure, a “floating SGSN” and an “anchored SGSN”.
In the “floating SGSN” solution, “floating” means that the control in the packet switched core network is transferred to the second serving node SGSN2 of the second routing area RA2 as soon as possible after a corresponding SRNC relocation procedure. In this case, as shown in FIG. 2B, the second serving node SGSN2 initiates an PDP context update by messages 12 to the gateway node GGSN as soon as it receives the SRNC relocation complete message 8 and before it sends the complete SRNC relocation message 10 to the first serving node SGSN1. The SGSN2 also informs a home location register (HLR) of the change of the serving node, which home location register in turn sends a cancel command to the first serving node SGSN. Thereafter, the SGSN2 sends a RA update command 13 to the user equipment UE which is forced by said command to perform a routing area update. This RA update command 13 is a layer 3 Mobility Management (MM) command. Upon receipt of the command 13, routing area update proceeds.
As a result of the above described “floating SGSN” solution, control in the packet switched core network is transferred from the first serving node SGSN1 to the second serving node SGSN2. Hence, data flows from the user equipment UE via the radio network controller RNC2 to the serving node SGSN2, to the gateway node GGSN and therefrom to the external network in uplink direction and vice versa in downlink direction. In this case the transfer of data is optimized. However, the “floating” solution requires a very long and complex signaling procedure. Additionally, the transfer of control between the SGSN1 and the SGSN2 takes place without the knowledge or even participation of the user equipment, since it is initiated by the serving radio network controller SRNC. In case the user equipment UE being in an active session leaves the coverage area during this process, it is not aware of switching the control to another routing area. When the user equipment UE tries to perform a routing area update or attach procedure on returning to the coverage area, PDP contexts may therefore be lost. Therefore, quality of service (QoS) may be affected.
The second solution for SGSN relocation mentioned above is an “anchored SGSN”. Herein, “anchored” means that the control in the packet switched core network is never transferred from the first serving node SGSN1 of the first routing area RA1. In this case the SRNC relocation procedure is performed as described above. Thereafter, with reference to FIG. 1, data flows as described above (UE→RNC2→SGSN2→SGSN1→GGSN→external network in uplink direction and vice versa in downlink direction). Unlike the “floating SGSN” solution described above, here the control of the core network remains at the first serving node SGSN1. Also, the second serving node SGSN2 does not initiate an update of PDP context to the gateway node GGSN. Therefore, the messages 12 and 13 in FIG. 2B can to be omitted. Hence, data are to be relayed from the first serving node SGSN1 to the second serving node SGSN2, which controls the second routing area RA2, in downlink direction and vice versa in uplink direction.
As a result, the “anchored SGSN” solution for inter SGSN relocation is a rather simple and robust procedure. Because no PDP context updates are required, none of the routing area update problems inherent in the “floating” solution apply. However, there is another drawback. Namely, the route across the core network from the current SGSN to the gateway node GGSN is not optimized, since each new serving node SGSN needs the foregoing SGSN(s) as relay stations to the GGSN. If the user equipment UE moves across several routing areas, three or even more serving nodes SGSN need to be involved within the communication. This is particularly wasteful for communication network resources, especially when the PDP context last for a long time (hours or even days).
In the post-published document WO 99/34635, there is disclosed a method for handing over a connection from one SGSN to another SGSN by giving the old SGSN a role of a temporary anchor.